Skip to content

docs(openspec): flag-level bash permissions proposal - #16

Open
preved911 wants to merge 3 commits into
mainfrom
openspec/flag-level-permissions
Open

preved911 wants to merge 3 commits into
mainfrom
openspec/flag-level-permissions

Conversation

@preved911

Copy link
Copy Markdown
Owner

Summary

OpenSpec change proposal for flag-level-permissions — adds granular, flag-aware command permission control. No implementation yet; this PR is the reviewed proposal (proposal → design → spec → tasks). Implementation follows via /opsx-apply.

Why

permission.bash globs match the whole command string, so flag-level intent can't be expressed reliably: "curl *": "ask" always catches curl -X GET https://api.com even if a narrower allow rule exists. Dangerous flags (find ... -delete, git push --force) deserve their own actions.

Proposed config

{
  "permission": {
    "bash": { "*": "ask", "git *": "allow" },
    "bash_args": [
      { "pattern": "curl -X GET *", "action": "allow" },
      { "pattern": "curl *", "action": "ask" },
      { "pattern": "find * -delete", "action": "ask" },
      { "pattern": "git push --force *", "action": "deny" }
    ]
  }
}

Key design decisions

  1. Token-based matching, anchored at command name — * matches zero+ whitespace tokens (find * -delete matches find /tmp -name "*.log" -delete, not plain find /tmp)
  2. First-match-wins in declaration order — specific rules before broad ones; avoids the dead-config trap of most-restrictive-wins
  3. Args rules take precedence over glob rules — falls back to existing permission.bash glob matching when no args rule matches
  4. Force-allow mechanism — flag allow overrides a native opencode ask via permission.ask (status = "allow"), without this the curl -X GET * → allow use case wouldn't work end-to-end
  5. Zero behavior change when permission.bash_args is absent

Artifacts

  • openspec/changes/flag-level-permissions/proposal.md — what & why
  • openspec/changes/flag-level-permissions/design.md — 7 decisions + risks
  • openspec/changes/flag-level-permissions/specs/args-permission-matching/spec.md — 5 requirements, 24 scenarios
  • openspec/changes/flag-level-permissions/tasks.md — 6 sections, 30 tasks

Next steps

  • Review proposal
  • Run /opsx-apply to implement (tasks 1–6)

Ultraworked with Sisyphus

preved911 and others added 3 commits September 3, 2026 03:20
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

👀 AI Code Review

Something went wrong: <urlopen error [Errno -2] Name or service not known>


Powered by GPT-4o via GitHub Models

@preved911

Copy link
Copy Markdown
Owner Author

It should be configured by bash guard plugin config (not in opencode's config). For commands, which matches items in config, should be processed this way. Old behavior with opencode permissions block based checks should continue working too.
I think, that good path for permissions checks should be: bash guard's config level -> opencode's permissions block level by bash guard -> opencode's permissions checks (if it required).

@preved911

Copy link
Copy Markdown
Owner Author

The config format should be different. For example:

permissions:
- tool: find
  args:
  - name: -delete
    behavoiur: ask
  - type: {{ arg.0 }}
    pattern: /Users/ivaliullin/work/*
    behaviour: allow

Less permission level should win.
Offer better naming for fields.

@preved911

Copy link
Copy Markdown
Owner Author

The config format should be different. For example:

permissions:
- tool: find
  args:
  - name: -delete
    behavoiur: ask
  - type: {{ arg.0 }}
    pattern: /Users/ivaliullin/work/*
    behaviour: allow

Less permission level should win.
Offer better naming for fields.

Do not forget about multi args cases and potential neested permissions declaration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant